The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Real-time Transport Protocol (RTP) and Real-time Transport Control Protocol (RTCP) have been designed to allow decentralized groups with minimal control to establish sessions, e.g. for multimedia conferences. A security profile for RTP (SRTP) and a security profile for RTCP (SRTCP) add confidentiality, message authentication, and replay protection to RTP. SRTP and SRTCP sessions typically require that synchronization source ID (SSRC) values and other data be coordinated among all of the participants in a real-time communications session. Therefore, SRTP and SRTCP sessions are typically not used in minimal-control scenarios. For example, if a new participant joins a real-time communications session that is already in progress, the new participant needs to obtain a sender's SRTP rollover counter (ROC) and the sender's encryption and authentication keys in order to process media messages form the sender.
A real-time communications session utilizing SRTP may require a central control mechanism, e.g., a dedicated server to poll each session participant in order to obtain and store the participants' keys, the participants' rollover counters, as well as other necessary information in a centralized manner. In some systems, RTP and RTCP may be used in conjunction with a signaling system that may be configured to provide some but not all of the coordination functionality required by SRTP.